Creating Human-like Synthetic Characters with Multiple Skill Levels: A Case Study using the Soar Quakebot

This paper reports on a preliminary attempt to develop and evaluate synthetic characters with multiple skill levels and with human-like behavior. Our goal was to determine which aspects of behavior have impact on skill level and humanness. We developed a bot that plays the computer game Quake against a human opponent. That bot can be parameterized along four dimensions: decision time, aggressiveness, number of tactics, and aiming skill. We then played variations of the bot against a human expert. Through empirical and human judgments we then evaluated the skill level and humanness of the variations. Our results suggest that both decision time and aiming skill are critical parameters when attempting to create human-like behavior. These two parameters could also be varied to modify the skill of the bots, and for some ranges, maintain the same level of humanness. The two primary goals of this research are to create synthetic characters with human-like behavior and varying levels of skill within the context of highly interactive tasks. The secondary goal is to develop and test a methodology for evaluating the humanness of synthetic characters in those types of tasks. Both primary goals require that we explore computational mechanisms for modeling human behavior and that we understand which behavioral parameters affect the humanness of the behavior and the skill of the behavior. Towards these ends, we have developed a parameterized AI system (called a bot) that plays the computer game Quake against humans. In developing the bot, we have tried to build an opponent that has the same strengths and weaknesses as human players. As part of its development, we parameterized the bot along four dimensions: decision time, aggressiveness, aiming skill, and tactical knowledge. This paper describes an evaluation of variations in those parameters in terms of different levels of skill and humanness. Our approach was to build versions of the bot with different parameter values and then play them against a "gold-standard" expert human player. Our results suggest that this methodology is useful, and that we could produce a range of skill levels using a subset of these parameters. Copyright © 2000, American Association for Artificial Intelligence (www.aaai.org). All rights reserved. The Soar Quakebot The Soar Quakebot (Laird, 2000; Laird & van Lent, 1999) plays the death match version of Quake II. In a death match, players exist in a "level", which contains hallways and rooms. The players can move through the level, picking up objects, called powerups, and firing weapons. The object of the game is to "kill" the other players. Each time a player is shot or is near an explosion, its health decreases. When a player's health reaches zero, the player dies. A dead player is then "spawned" at one of a set of spawning sites within the level. Powerups, which include weapons, health, armor, and ammo, are distributed throughout the level in static locations. When a powerup is picked up, a replacement will automatically regenerate in 30 seconds. Weapons vary according to their range, accuracy, spread of damage, time to reload, type of ammo used, and amount of damage they do. The Soar Quakebot controls a single player in the game. We have attempted to make the perceptual information and motor commands available to the bot similar to those that a human has while playing the game. For example, a bot can see only unobstructed objects in its view cone and it can hear only nearby sounds. One issue is that bots cannot sense the walls as coherent objects because they consist of many polygons that give the appearance of solid walls, open doorways, etc. To navigate, the Quakebot explores and builds up an internal map based on range data to walls. The Quakebot uses this map to know where walls, rooms, hallways, and doors are when it is running through a level. Once a map is built, it can be saved for later use when the Soar Quakebot replays the level. The Quakebot uses Soar (Laird et al., 1987) as its underlying AI engine. The Soar Quakebot is designed based on the principles developed early on for controlling robots using Soar (Laird and Rosenbloom 1990) and then extended in our research on simulating military pilots in large scale distributed simulations (Jones, et al. 1999). All the knowledge for playing the game, including constructing and using the internal map, is encoded in Soar rules. The Soar Quakebot evaluated in this paper has 100 operators, of which 20 have substates, and 715 rules. The underlying Quake II game engine updates the world ten times a second (the graphics engine updates much more often than the game engine). On each of these cycles, all changes to the bot's sensors are updated and any requested motor actions are initiated. In this configuration, Soar runs asynchronously to Quake II and executes its basic decision cycle anywhere from 30-50 times a second, allowing it to take multiple reasoning steps for each change in its sensors. Nominally, Soar runs as fast as possible, consuming 5-10% of the processing of a 400MHz Pentium II running Windows NT.